REMARKS 



The above amendment and these remarks are responsive to 
the Office Action of Examiner Sean M. Reilly dated 1/29/2007 
and of Examiner Aaron N. Strange dated 9/21/2007. 

Claims 1-106 are in the case, none as yet allowed. 

Interview 

Applicants' attorney expresses appreciation for 
courtesy extended by Examiner Reilly in a telephone 
interview on 13 Jun 2007. Applicant indicated that the new 
matter rejection would be traversed, and inquired as to 
whether a responsive amendment would require the 
cancellation of the amendment to the specification which 
gave rise to the objection. The Examiner indicated that the 
new matter rejection would be withdrawn, and cancellation of 
the amendment to the specification would not be required. 

Response to Arguments 

The Examiner states 

"In response to Applicant's request for 
reconsideration filed on September 18, 2006 and 
November 11, 2006 the following factual arguments are 
noted. 
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a. Applicant's amendments to the claims overcome the 
outstanding 35 U.S.C. 101 rejection. " 

b. The combination of Chen and Boe is improper and 
fails to disclose the claimed direct negotiation 
session communication between the client and 
server." [Office Action, page 2.] 

In considering a., the Examiner objects to the use of 
the word "tangible" in claims 105 and 106, and to an 
amendment made to the specification paragraph 24. 

Applicants have removed the word "tangible" from claims 
105 and 106, replacing it with "physical". The amendment to 
the specification paragraph 24 will be discussed hereafter. 

In considering b., the Examiner states: 

"...in the current 103 rejection Examiner proposes 
modifying the telnet negotiation of Chen to include the 
negotiations of Boe utilized between the TN3270 server 
and host mainframe 12." [Office Action, pages 3-4.] 

The current 103 rejection will be discussed hereafter. 

Specification 

The Examiner objects to the previously entered 
amendment to the specification, which was filed 20 Apr 2006, 
finding that "...the amendment to paragraph [sic, page] 24 
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line 16 constitutes new matter because of the new scope of a 
computer program product or a program element, or a program 
storage or memory device is not supported by the original 
disclosure . " This is the amendment presented and previously 
entered: 

It will be appreciated that, although specific 
embodiments of the invention have been described herein 
for purposes of illustration, various modifications may 
be made without departing from the spirit and scope of 
the invention. In particular, it is within the scope 
of the invention to provide a computer program product 
or program element, or a program storage or memory 
device such as a solid or — fluid transmission medium, 
magnetic or optical wire, tape or disc, or the like, 
for storing signals readable by a machine, for 
controlling the operation of a computer according to 
the method of the invention and/or to structure its 
components in accordance with the system of the 
invention . -- . 

Applicants traverse, and are advised that the objection 
is to be withdrawn. 

An applicant is generally free to change an application 
after it has been filed if the proposed changes are 
supported, or described, by the original application. In a 
sense, anything inserted in a specification that was not 
here before is new to the specification but that does not 
necessarily mean it is prohibited as "new matter". 
Prohibited new matter is that which is not found in the 
specification... as first filed, and that involves a 
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departure from the original invention [Robinson on Patents 
561 (1890)]. The rule against new matter is intended to 
prevent an applicant (under the guise of an amendment) from 
introducing into his application a wholly different 
invention, or changing the construction of a fully disclosed 
invention, or presenting a different or preferred form of 
the invention. [In re Oda, 443 F.2d 1200, 170 USPQ 268, 
270-271 (C.c.P.A. 1971) . ] 

In this case, the proposed changes are supported by the 
original application, and they do not consist of an 
insertion . That is, every aspect of the definition of the 
scope of "memory device..." existing in the definition after 
the amendment was included in that definition before the 
amendment. Nothing new is added. There is here no 
broadening of the definition for memory device. Further, as 
would be apparent to those of skill in the art, applicants 
had possession of the subject matter defined by the phrase 
"such as a magnetic or optical tape or disc, or the like, 
for storing signals..." as the application was originally 
filed. 

The amendment to which the Examiner objects merely 
removes "solid or fluid transmission medium" from the scope 
of the definition of memory device, and adds nothing to it. 
The resulting scope of the definition is diminished, not 
broadened. There is in doing so no prejudice to the public. 
Nothing is removed from the public domain in narrowing the 
scope of equivalents to which the claims are entitled, and 
there certainly is a public interest in allowing it to be 
done. In making this amendment, applicants hope to 
facilitate prosecution to allowance while reserving the 
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right to file a continuation application to recover the 
material removed. 

The Examiner required that applicant "cancel the new 
matter in the reply to this Office Action." [Office Action, 
page 2, emphasis added.] As noted above, applicants have 
been advised by the Examiner that this requirement is being 
withdrawn . 



35 U.S.C. 101 

Claims 71-106 have been rejected under 35 U.S.C. 101 as 
directed to non-statutory subject matter. 

As suggested by the Examiner [Office Action, page 2], 
applicants have amended these claims by limiting the scope 
of a computer readable storage medium such that solid and 
fluid transmission mediums are excluded. This is done by 
the amendment to page 28 of the specification, removing such 
transmission mediums from the definition of storage device, 
and by reciting in the claims the use of a physical program 
storage device. 

Therefore, applicants urge that the rejection under 35 
U.S.C. 101 of claims 71-106 be withdrawn. 



35 U.S.C. 112 

Claims 1-106 have been rejected under 35 U.S.C. 112, 
first paragraph, for the use of the term "legacy host". 
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Applicants have amended the claims to refer to "host", which 
is referenced at several locations in the specif ication, 
particularly at page 17, line 6 to page 18, line 1. 

The host operations being described as processing of 
the client based on IP address, device requested, auto- 
signon is not part of any Telnet protocol, but is based on 
information passed from the Telnet negotiations. In other 
words, the Telnet negotiations do not "auto-signon a 
client", for example, but instead an exit program on the 
host is called to perform this function. ^a^@V r 3-^"> '■ 1- ':Ibv^:5 
22 refers t-o a/n "'escBt progra^ Bufe on the host. 

Applicants request that the rejection under 35 U.S.C. 
112 be withdrawn. 

35 U.S.C. 103 

Claims 1-106 have been rejected under 35 U.S.C. 103(a) 
over Boe et al. (U.S. Patent 6,122,276, hereinafter Boe) , 
Chen et al. (U.S. Patent 6,182,220, hereinafter Chen), and 
Murphy et al . (RFC 287, "5250 Telnet Enhancements", July 
2000, hereinafter Murphy) . 

Applicants have amended all independent claims 1, 18, 
23, 32, 49, 58, 63, 71, 88, 105, and 106 in various ways to 
clarify the server/client connection negotiations and the 
server exit program/host application processing undertaken 
in practicing their invention, which include the following: 

1. Client connects to server (such as a Telnet 
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server) , and possibly starts protocol 
negotiations. (Not all clients start this, some 
wait for the server to start it.) 

2. The server starts negotiations and invites the 
client to negotiate terminal type and to send any 
environment variables it has. 

3. The client sends normal negotiations of terminal 
type, and also the new environment variable 
(IBMSENDCUSTOMCONFREC) with value being a blank 
delimited list. 

4. The server calls an exit program to act on the 
value received in the IBMSENDCUSTOMCONFREC 
variable (that is, shells the variable out to a 
host program external to the server.) The host 
provides back to the server exit program a result 
that needs to be returned to the client. 

5. The server concludes negotiations with the client 
and finally sends in the Confirmation Response as 
custom data any user exit result received from the 
host, where custom data may be one of the items 
from the blank delimited list, indicating that 
this item was selected and used. 

The exit programs do not negotiate the connection, that 
is done by the server and client. Further, data may flow in 
both directions: blank delimited list from client to server, 
and exit program results from server to client. 
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In applicants' invention, "exit programs" are used to 
run special or custom action. 

Applicants' specification Figure 3 element 72 and Table 
7 show "IBMSENDCUSTOMCONFREC" as a new "parameter" from the 
client to the server, which directs the server to send a 
response ("return codes") as described by Figure 2 back to 
the client. 

Boe's use of "confirmation record" applies to a 
transport protocol (SNA) and is mandatory, while applicants 
use applies to Telnet, or the like, and is negotiable. 
Telnet is not a transport protocol. The comparable 
transport protocol for applicants would be "TCP/IP". Telnet 
is a communications layer that rides on top of the transport 
protocol . 

What Boe describes are not Telnet negotiations but SNA 
negotiations, and applicants argue that one of ordinary 
skill in the art would not consider that mandatory SNA 
negotiations would teach negotiable TCP/IP negotiations. 
Boe relates to SNA communications between the host and the 
TN3270 server, and not between the host and the TN3270 
client. Further, applicants invention relates to 
negotiations between a server, such as a Telnet server, and 
client. While applicant's invention relies on exit programs 
for accessing host applications, such exit programs are not 
involved in the negotiations setting up a persistent 
connection of client to server. 

The Examiner asserts that it is obvious to combine 
Murphy and Chen, using device names (as indicated by Murphy) 
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in Chen for the graphical display. Murphy, page 6, relates 
to display devices, and the attributes mentioned are display 
device attributes rather than session attributes. Since not 
all attributes negotiated are pertinent to the display 
device, is would be improper to state the other "custom" 
attributes are tied to the device name. For example, a user 
profile and password have nothing to do with having logged 
on to a color display terminal with 27 rows and 132 columns. 
Certainly, the profile, password, terminal-type, binary 
mode, and end-of-record are all associated with this Telnet 
session, but only some of these negotiations are associated 
with the device name. Therefore, applicants respectfully 
submit, there is no proper basis for using "session name" 
and "device name" interchangeably. 

Thus, applicants traverse the Examiner's linkage of 
Chen and Murphy inasmuch as the profile and password 
negotiations are, in truth, not related to "session name" or 
"device name", since they are temporary for authentication 
and must be exchanged securely. They are not stored or 
displayed in the "session" or "device", and should not be 
since that is not secure. 

The Examiner refers to Chen as teaching "executing exit 
programs". Applicants find no such teaching in Chen. Chen 
is only showing how encrypted passwords are exchanged, and 
this does not require exit programs, and thus exit programs 
are not implicitly taught by Chen, nor are the explicitly 
taught. The programmable negotiations in Boe are TN3270 
negotiations (similar in certain respects to Telnet 
negotiations) , and these do not constitute "exit program 
processing". Col. 5, lines 25-28 is nothing more that 
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TN3270 negotiations , and these do not involve exit programs. 
An exit program, as will be apparent to those of skill in 
the art, needs to be a "hook" or "call" to an external 
program, meaning external to the Telnet server. Thus, exit 
programs are not bound by Telnet negotiations and can act 
solely on the information passed to it. The Examiner errs 
is equating exit programs to Telnet, or the like, 
negotiations . 

With respect to claim 1, the Examiner states as 
follows : 

"Chen disclosed a method for processing a client 
(telnet client f figure 1) session request received at a 
server in a system including a client and a server with 
both server and client executing exit programs for 
negotiating a confirmation record on a session 
connection. . ." [Office Action, paragraph 5.] 

Applicants traverse this reading of Chen, and argue that 
Chen does not disclose "exit program" processing. To 
clarify this distinction, applicants have amended claim 1 to 
further define exit program processing, as follows: 

" executing an exit program for calling and passing said 
user variable to a host application at said host 
external to said server, said host application 
processing said user variable and responsive thereto 
returning custom data to said server, said custom data 
selectively including a user variable received from 
said client that was selected and used; and 
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said server concluding negotiating said environment 
parameters with said client selectively including 
sending to said client a confirmation record and custom 
record including said custom data received from said 
exit program . . . " 

The Examiner continues by discussing the following 
three distinctions in claim 1 with respect to Chen: 

Chen disclosed substantial features of the claimed 
invention however, Chen failed to specifically recite: 
1) said client including a graphical user interface 
selectively assigned a session name enabling client 
emulator communication at an application layer with 
said server, 2) responsive to receiving a user variable 
requesting a custom confirmation record received at 
said server from said client, said server sending to 
said client a confirmation record and custom record 
data for enabling said client to engage in subsequent 
programmable negotiations directly with said server, 
and 3) a legacy host in the system. [Office Action, 
Paragraph 5 . ] 

With respect to point 1, the Examiner references 
Murphy. With respect to points 2 and 3, the Examiner 
references Boe . 

With respect to point 1, applicants respond that the 
combination of Chen and Murphy does not teach exit program 
processing. The Chen and Murphy protocols are 
"architectural", in the sense that the customer may not 
customize the confirmation record (of Murphy) without 
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modifying application code. Applicants' invention allows 
the creation, or customization, of any type of confirmation 
record through the use of exit program functionality, this 
being the sense in which claim 1 refers to "custom record.' 7 

With respect to point 2, the Examiner states that Boe 
and Chen may be combined as follows: 

"...incorporate the telnet negotiation scheme disclosed 
by Boe within Chen's system, in order to further expand 
the compatibility of Chen's system, by enabling telnet 
clients to communicate with telnet servers that utilize 
the old proprietary SNA server protocol or protocols 
derived from the old proprietary SNA server 
protocol . . . " 

"In an analogous telnet system, Boe disclosed 
negotiating environment parameters for establishing a 
telnet session between a client (TN3270 server) and a 
server (Host Mainframe 12) (see inter alia, figure 4) . 
Boe further disclosed responsive to receiving a user 
variable requesting a custom confirmation record 
received at said server from said client, said server 
sending to said client a confirmation record (line D, 
fig. 4) ; host sends a confirmation response to 
requesting client via the server to signify a 
connection and custom record data for enabling said 
client to engage in subsequent programmable 
negotiations directly with said server (line E, fig. 4, 
col. 5, lines 25-28., in response to the client 
request, host sends custom record data (local address 
x) to client, thus forming a custom confirmation 
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record). [Office Action, pages 8-9.] 



As previously discussed, Boe's use of "confirmation 
record" applies to a transport protocol (SNA) and is 
mandatory, while applicants use applies to Telnet, or the 
like, and is negotiable. Telnet is not a transport 
protocol. The comparable transport protocol for applicants 
would be "TCP/IP". Telnet is a communications layer that 
rides on top of the transport protocol. 

Referring to Boe's figures, applicants are dealing with 
the entire path (lines 16 and 20 but without relay or 
converter 18) from host mainframe 12 to client 14, whereas 
the Examiner is speaking of functionality (i.e., 
confirmation record processing) only available on the SNA 
path represented by line 20. In Boe, line 20 is SNA and 
line 16 is TCP/IP, requiring the presence of server 18 as 
converter, or gateway, between host 12 and client 14. 
Consequently, there is not negotiation of environment 
parameters between host 12 and client 14, but rather between 
host 12 and 18 - and this is not what applicants are 
claiming . 

Thus, Boe does not teach the claim 1 limitations of: 

"... said client and said server negotiating environment 
parameters for establishing a connection-oriented 
connection of said server with said client, said client 
and said server communicating over said connection 
using a same client/server communications 
protocol ... said server executing an exit program for 
calling and passing said user variable to a host 
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application at said host external to said server, said 
host application processing said user variable and 
responsive thereto returning custom data to said 
server, said custom data selectively including a user 
variable received from said client that was selected 
and used . . . " [Claim 1, as amended.] 

With respect to point 3, as previously discussed with 
respect to the 35 U.S.C. 112 rejection, applicants have 
amended the claim to remove reference to "legacy" host. 

With respect to claim 18, the Examiner states: 

Claim 18 is rejected for similar reasons as claim 1 
addressed above. Boe further teaches client (18, fig. 
1) /server (20, fig. 1) system; a user exit program 
running on said server (abstract) ; said client 
operating in conjunction with said user exit program 
for requesting said custom confirmation record (lines A 
and B, fig. 4). [Office Action, paragraph 6.] 

Applicants respond by noting that Boe has an extra 
level of indirection due to the SNA path 20. Any exit 
program would be on the SNA path, and therefore can't be 
done on the TCP/IP side. Further, applicants argue, Boe 
never teaches an exit program running on a server. Lines A 
and B of Boe Figure 4 are not an exit program in the sense 
of claim 18, which refers to an exit program where there is 

" a host application program module for receiving from 
said exit program a user variable provided to said 
server bv a client request for a custom confirmation 
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record and responsive thereto for returning to said 
server custom data selectively including said user 
variable; said server further for sending to said 
client a confirmation record including said custom 
data . " [Claim 18] 

There is no teaching in Boe that such an exit program is 
defining the negotiation an lines A and B in the manner of 
claim 18. 

With regard to claims 2, 33, 59, 64, 72, 89, the 
Examiner states 

"Chen disclosed negotiating, inviting, and sending 
steps executing within the application layer of a 
TCP/IP protocol stack (Chen Figure 1, TCP/IP is the 
protocol used for communication) . " [Office Action, 
paragraph 7 . ] 

These claims all depend from base claims in which 
confirmation records are negotiated using exit program 
functionality, and therefore are distinguished from Chen as 
previously discussed with respect to claims 1, 18 and 
hereafter with respect to the other independent claims in 
the case. 

With respect to claim 3, the Examiner states: 

"...Boe teaches the step responsive to a user variable 
requesting a confirmation record, sending to said 
client a confirmation record without said custom record 
data (Fig. 4, line E) . " [Office Action, paragraph 8.] 
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Applicants respond that Boe line E teaches in 
connection with line E a confirmation of delivery in SNA 
protocol. This is an architected or defined protocol 
response in the sense that there is no manipulation or 
customization of it by an user exit, as previously discussed 
with respect to claim 1, from which claim 3 depends. 

With respect to claims 4-6, which depend from claim 1, 
the Examiner states: 

Boe further teaches the confirmation record including a 
field defining a pass through data length f said pass 
through data including said confirmation record and 
said custom record data (RU, fig. 2, col. 4, lines 
38-40, lines 64-66; col. 5, lines 7-10, lines 25-28; RU 
(Request/Response Unit) field includes subfields that 
indicate various data parameters of the 
request/response/packet) ; appending said custom record 
data to said confirmation record (line E, fig. 4; in 
addition to default response stated in claims 2-3 
above, updated responses also includes custom record 
data x) . [Office Action, paragraph 9.] 

As with claim 1, applicants respond that the 
confirmation record of claims 4-6 are custom (that is, 
dynamic in the sense of defined by exit program processing) . 
Boe' s is not . 

With regard to claims 7-8, which depend from claim 1, 
the Examiner states: 

"...Boe further teaches the request being for a defined 
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custom confirmation record, said request including a 
list of one or more predefined information items (local 
address x) , further comprising the step of sending to 
said client defined data in said custom record data 
(line E, fig. 4)." [Office Action, paragraph 10.] 

Applicants traverse and respond that Boe does not teach 
a "custom" confirmation record. Rather, Boe's confirmation 
record is architecturally defined, and not defined by a 
customer exit as in applicants' claims 1, 7, and 8. 
Applicants' exit program can define a unique confirmation 
record to be used during protocol negotiations, and this is 
not taught by Boe, or Chen, or Murphy. 

With respect to claims 9-12 and 17, the Examiner 
states : 

"Boe teaches providing in said custom record data 
indicia identifying a device, terminal , associated 
device (line C, fig. 4., device model=ml) allocated by 
a host server; physical location (line C, fig. 4., 
local address=x) for receiving output; and custom 
information for interpretation by said client (col. 5, 
lines 25-29; host sends custom response record to 
client. )" [Office Action, paragraph 11.] 

Applicants respond that Boe works with predefined variables, 
and in the sense of using such predefined variables may be 
considered "custom". However, Boe does not teach the 
processing of confirmation records nor exit program 
functionality as previously discussed with respect to claim 
1, from which these claims depend. These claims 9-12 and 17 
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refers to the confirmation record providing back to the 
server a preferred location for printing. This requires a 
user defined exit to customize the connection, and this is 
not taught by Boe . 

With respect to claims 13-16, in paragraph 12 of the 
Office Action, the Examiner states: 

"As per claims 13-16, Boe teaches the client 
negotiating with the host to establish a connection 
(line B, fig. 4). Boe further teaches plurality of new 
clients trying to log on and negotiating with the host 
for service connection (lines M, N, fig. 4) . However, 
Boe does not specifically disclose providing in custom 
record data indicia identifying system security level 
and password encryption requirements , another device 
for retrying a rejected request, a reason for a failed 
auto-signon request, and a reason for denial of session 
connection request upon system overload and redirection 
to an alternate time or host. 

Nonetheless providing such information to clients 
logging into telnet system was widely known at the time 
of the invention, as evidenced by Murphy. In an 
analogous art, Murphy disclosed a standard for telnet 
clients and servers to communicate (Abstract) . 

Murphy's description in RFC 5250 discusses negotiating 
environment variables, but there is no teaching of exit 
program processing. Unlike Murfphy, applicants provide that 
through use of exit programs this can be dynamically 
redefined (that is, customized) by customers. Applicants 
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create customized confirmation records that are defined by 
user exit programs. 

The Examiner continues: 

"Murphy ' s protocol provides clients logging into a 
telnet system with detailed custom record data response 
codes for use in establishing and debugging connections 
(Murphy see inter alia pgs-20 and 21 Response codes) . " 

Murphy does teach response codes, but these are static, 
predefined response codes and not custom codes defined by an 
exit. Murphy teaches in Figure 1 direct encapsulation of 
SNA protocol, a proprietary architecture. These are 
predefined pass-through records for the 5250 SNA data 
stream, and are not dynamic, or custom, response codes. 
This is not communicating with a user exit, but with the 
operating system kernel. This is a predefined list in 
accordance with a private protocol. The pass through header 
in Figure 2 is a 12 byte header, all predefined as explained 
in the caption below Figure 2. This is pass through data, 
and has nothing to do with a protocol defined in an exit 
program. 

The Examiner continues: 

"The response information includes identifying system 
security level and password encryption requirements 
(Murphy see pgs 7 and 8) , another device for retrying a 
rejected request, a reason for a failed auto-signon 
request, and a reason for denial of session connection 
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request upon system overload and redirection to an 
alternate time or host (see inter alia pgs 20 and 21 
Response codes) . " 

Again, Murphy teaches a rigid or predefined protocol, not 
one which is custom and configured by exit programs. 

With respect to claim 19, the Examiner states: 

As per claim 19, Boe teaches client being a Telnet 
client (e.g. the TN3270 Server receives telnet session 
information from the Host mainframe Figure 4, lines D 
or E) . [Office Action, paragraph 13.] 

Applicants traverse. In Boe, the 3270 client 14 and 
server 18 communicate on line 16 using TCP, and the host 12 
and server 18 communicate on line 2 0 using SNA . So lines D 
and E are not telnet, but rather SNA. 

In paragraph 14 of the Office Action, claims 20 and 22 
are rejected for similar reasons as claims 1-8 and 18 
addressed above. In response, please refer to the 
discussion of claims 1-8 and 18. 

In paragraph 15 of the Office Action, claims 21, 44-47, 
83-86, 100-103 are rejected for similar reasons as claims 
13-16 addressed above. In response, please refer to the 
above discussion of claims 13-16. 

In paragraph 16 of the Office Action, claims 23, 32, 
49, 58, 63, 71, 88, 105, and 106 are rejected for similar 
reasons as claim 1 addressed above. Boe further teaches 
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negotiating environment parameters for establishing a 
connection-oriented connection with said server (lines B, C, 
fig. 4; environment parameters include PSIO, Power on, 
LocAdd-x, etc . ) 

In response, applicants refer to the previous 
discussion of claim 1. Further, with respect to Boe, 
applicants agree that Boe teaches negotiating environment 
parameters, but this is only done within the limits of a 
predefined protocol. Applicants negotiate enviornment 
parameters as defined by user written exit programs. Unlike 
Boe, applicants can dynamically customize the protocol. 

In paragraph 17 of the Office Action, claims 34, 60, 
65, 73, 90 are rejected for similar reasons as claims 3 
above. Applicants respond as previously discussed with 
respect to claim 3. 

In paragraph 18 of the Office Action, claims 35-37, 
61-62, 66-68, 74-76, 91-93 are rejected for similar reasons 
as claims 4-6 above. Applicants respond as previously 
discussed with respect to claims 4-6. 

In paragraph 19 of the Office Action, claims 38-39, 
69-70, 77-78, 94-95 are rejected for similar reasons as 
claims 7-8 above. Applicants respond as previously 
discussed with respect to claims 7-8. 

In paragraph 20 of the Office Action, claims 40-43, 48, 
79-82, 87, 96-99, and 104 are rejected for similar reasons 
as claims 9-12 and 17 above. Applicants respond as 
previously discussed with respect to claims 9-12 and 17. 
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Applicants urge that claims 1-106 be allowed. 



SUMMARY AND CONCLUSION 

Applicants urge that the above amendments be entered 
and the case passed to issue with claims 1-106. 

The Application is believed to be in condition for 
allowance and such action by the Examiner is urged. Should 
differences remain, however, which do not place one/more of 
the remaining claims in condition for allowance, the 
Examiner is requested to phone the undersigned at the number 
provided below for the purpose of providing constructive 
assistance and suggestions in order that allowable claims 
can be presented, thereby placing the Application in 
condition for allowance without further proceedings being 
necessary . 

Sincerely, 

R. G. Hartmann, et al . 
By 

Shelley III Beckstrand 
Reg. No. 24,886 

Date: 8 Oct 2007 

Shelley M Beckstrand, P.C. 
Patent Attorney 
61 Glenmont Road 
Woodlawn, VA 24381-1341 
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Phone: (276) 238-1972 
Fax: (276) 238-1545 
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